SliceDict, a sliceable dictionary #313
Conversation
|
This looks great! I'm not sure what to do with the int argument to Should we, as part of this same PR, also concert dicts on the way in ( |
The problem here is the following: Say you have two values, np.zeros(10) and np.zeros((10, 5)). If you slice by int, you get back a scalar and an np.zeros(5). That would not work well with SliceDict, since they don't have equal shape[0]. We could implicitly shape back to the original dimensionality, but that would be an unexpected behavior differing from np.array. My suggestion with progress would be to see where it's possible to replace dict in nolearn code, where not, and where more adaptations are necessary. |
| @@ -180,3 +183,53 @@ def get_conv_infos(net, min_capacity=100. / 6, detailed=False): | |||
| receptive_fields.astype(int))) | |||
|
|
|||
| return tabulate(table, header, floatfmt='.2f') | |||
|
|
|||
|
|
|||
| class SliceDict(dict, object): | |||
There was a problem hiding this comment.
AFAIK dict is already a new-style class so you could drop the object.
There was a problem hiding this comment.
Yeah, I started out with UserDict, that's why I had it in there.
OK, let's raise a
Sounds good. Do you want to add implicit conversions + warnings to those methods in this PR? There's a few tests that will help, though they probably won't catch all the corner cases. For the check before the implicit conversion we probably want to do something like |
Only basic implementation yet, not finished.
Idea: When wrapping dict input in a SliceDict, we could hopefully the reduce number of
if isinstance(X, dict) ... else ...but probably not to 0.Open points:
shapeattribute? If so, should it only return(shape[0],)?Would solve this issue.